home *** CD-ROM | disk | FTP | other *** search
/ Turnbull China Bikeride / Turnbull China Bikeride - Disc 2.iso / BARNET / ARMLINUX / MAIL / 9801 / 000066_owner-linux-arm…r.rutgers.edu _Mon Jan 12 21:36:06 1998.msg < prev    next >
Internet Message Format  |  1998-01-31  |  3KB
  1. Return-Path: <owner-linux-arm-outgoing@vger.rutgers.edu>
  2. Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
  3.     by odie.barnet.ac.uk (8.8.6/8.8.6) with ESMTP id VAA07911
  4.     for <willy@odie.fluff.org>; Mon, 12 Jan 1998 21:36:05 GMT
  5. Received: from vger.rutgers.edu ([128.6.190.2]:18012 "EHLO vger.rutgers.edu" ident: "root") by nic.funet.fi with ESMTP id <10774-27083>; Mon, 12 Jan 1998 23:26:19 +0200
  6. Received: by vger.rutgers.edu id <971178-241>; Mon, 12 Jan 1998 15:51:04 -0500
  7. Received: from snowcrash.cymru.net ([163.164.160.3]:1504 "EHLO snowcrash.cymru.net" ident: "NO-IDENT-SERVICE") by vger.rutgers.edu with ESMTP id <971135-241>; Mon, 12 Jan 1998 15:00:54 -0500
  8. Received: (from alan@localhost) by snowcrash.cymru.net (8.8.7/8.7.1) id UAA11083; Mon, 12 Jan 1998 20:02:52 GMT
  9. From: Alan Cox <alan@cymru.net>
  10. Message-Id: <199801122002.UAA11083@snowcrash.cymru.net>
  11. Subject: Re: ARMlinux vs. RiscBSD
  12. To: neil@causality.com (Neil A. Carson)
  13. Date:     Mon, 12 Jan 1998 20:02:51 +0000 (GMT)
  14. Cc: alan@cymru.net, msergio@tin.it, linux-arm@vger.rutgers.edu
  15. In-Reply-To: <34BA61DA.41C67EA6@causality.com> from "Neil A. Carson" at Jan 12, 98 06:32:58 pm
  16. Content-Type: text
  17. X-Orcpt: rfc822;linux-arm@vger.rutgers.edu
  18. Sender: owner-linux-arm@vger.rutgers.edu
  19. Precedence: bulk
  20. Status: RO
  21.  
  22. > the filesystem will still be dirty anyway so stuff would be constructed
  23. > automatically upon fsck. What I believe is that it reduces the
  24.  
  25. What occurs is that the Linux case you lose the last few writes, the BSD 
  26. case you lose the last few data writes
  27.  
  28. > likelyhood of manual intervention being required at fsck time (ie major
  29. > inconsistencies that are not automatically solvable, rather than more
  30. > minor ones) so that more files tend to be lost+founded or i-nodes
  31. > cleared.
  32.  
  33. Actually that isnt the case. It requires your fsck is a fraction smarter
  34. but not significantly. The main issue is deleted files.
  35.  
  36. > Some recent research into log-structured filesystems (I believe there
  37. > was a Linux log-structured project) by the FreeBSD guys---as they've
  38.  
  39. Yep. And theres also a journalled ext2fs project which is fairly
  40. similar to McKusicks work but a lot simpler in its approach. (NTfs btw
  41. is very similar in its algorithms to McKusicks work)
  42.  
  43. > are in fact a waste of time compared to McKusicks funky stuff, apart
  44. > from the decreased fsck time of course.
  45.  
  46. For ARM stuff the important thing to most folks is that if you flip the
  47. switch you cannto damage any data.
  48.  
  49. Alan
  50. unsubscribe: body of `unsubscribe linux-arm' to majordomo@vger.rutgers.edu